前言：「在我的環境上測試都過了」，這句話到底測了幾種環境？

「這次改動我跑過測試了，全部綠燈，應該沒問題。」

這句話聽起來很安心，但如果你維護的是一個需要適配多種執行環境的工具，這句話背後藏著一個沒問出口的問題：「跑過測試」指的是哪一種環境組合？

這個專案（PHPUnit & Pest Test Explorer）支援的執行方式就有好幾種：直接在本機執行、透過 Docker 容器執行、透過 SSH 連到遠端主機執行、透過 Laravel Sail 這種包了一層 Docker Compose 的開發環境執行，還要搭配 ParaTest 平行測試、Xdebug 逐行除錯——光是把這幾個維度隨意組合，可能的執行環境就有十幾二十種。今天要講的是：AI 判斷「這次改動安不安全」時，天然只驗證了它自己方便跑的那一種環境，而不是使用者實際會遇到的那一種。

今日目標

• 理解「本機測試通過」在多環境專案裡是一個範圍很窄的宣稱
• 認識測試矩陣隨環境維度增加而組合爆炸的具體樣貌
• 學會用「這次改動碰到了哪個維度」來判斷該驗證哪些環境組合，而不是全部都測
• 建立「AI 驗證過的環境」跟「使用者實際會用的環境」之間的落差意識

這個專案的環境維度長什麼樣

把這個專案支援的執行方式攤開來看，至少有三個彼此獨立的維度：

• 執行位置：本機直接執行、Docker 容器內執行、透過 SSH 連到遠端主機執行
• 框架/工具組合：純 PHPUnit、Pest、搭配 ParaTest 平行執行
• 除錯模式：一般執行、掛載 Xdebug 逐步除錯

這三個維度不是互斥選項，而是可以自由組合的——使用者可能在 Docker 容器裡跑 Pest 搭配 ParaTest，也可能透過 SSH 連到遠端主機跑純 PHPUnit 並掛 Xdebug。光是這三個維度隨意排列組合，可能的執行環境數量就足以讓「我在本機測過了」這句話,實際上只覆蓋了整個矩陣裡極小的一塊。

AI 天然會驗證哪一種環境

當 AI 被要求「確認這次改動沒有破壞既有功能」，它預設會選擇成本最低、最方便驗證的路徑——通常就是本機直接執行、不透過任何容器或遠端連線的那一種。這個選擇本身沒有錯，是最快能拿到回饋的方式，但它悄悄縮小了「已驗證」的實際範圍。

用一組對照來看這個落差：

❌ 只驗證預設環境：
「這次改動了路徑解析邏輯，我在本機執行測試，全部綠燈，
 這個改動應該是安全的。」
→ 「安全」這個結論的查證範圍只涵蓋本機直接執行這一種環境，
  沒有涵蓋 Docker 容器內部路徑（容器內外路徑不一致）、
  SSH 遠端主機（本機路徑跟遠端路徑本來就是兩套檔案系統）
  這幾種同樣真實存在、且路徑解析邏輯特別容易出問題的組合

✅ 標注驗證範圍，並判斷這次改動碰到了哪個維度：
「這次改動了路徑解析邏輯——這個邏輯在 Docker/SSH 環境下
 需要額外的路徑映射處理，屬於高風險維度。
 已在本機驗證通過；容器內路徑映射與遠端路徑解析
 這兩種環境還沒驗證過，建議至少補一組容器環境的驗證，
 因為這次改動的性質剛好落在這兩種環境最容易出錯的地方。」
→ 不是要求每次改動都跑遍所有組合（成本太高），
  而是先判斷「這次改動碰到了哪個維度」，
  再決定這個維度底下哪些環境組合值得驗證

這正是這個系列反覆出現的模式的另一種樣貌：AI 給出「已驗證沒問題」的結論，查證範圍只涵蓋它實際跑過的那一種環境——如果改動性質剛好落在沒驗證到的維度上，這句「安全」就只是一句沒有依據的自信。

不是每次都要測遍矩陣，而是要判斷「這次碰到了哪個維度」

把整個測試矩陣的每一種組合都跑一遍，對日常開發來說成本太高，也不現實。真正可行的做法，是先分辨「這次改動性質上會不會碰到某個維度特有的行為」：

• 改動的是純字串處理、跟檔案系統/網路連線完全無關的邏輯 → 本機驗證通常已經足夠
• 改動的是路徑解析、檔案 I/O、跨程序通訊 → 容器內外路徑不一致、遠端連線延遲這類問題特別容易在這裡冒出來，值得額外驗證至少一種容器/遠端環境
• 改動涉及測試執行的時序、輸出解析 → 搭配 ParaTest 平行執行時的行為值得額外確認

這份「哪一類改動該碰哪一種環境」的對照表，本身就是把「AI 沒辦法窮盡驗證整個矩陣」這件事，收斂成「AI 可以判斷這次改動屬於哪一類、該不該多驗證一種環境」的具體問題。

今日思考題

回想你維護的專案：如果它需要適配多種執行環境（不同作業系統、不同部署方式、不同資料庫），你的測試矩陣設計是「每次都跑一遍所有組合」，還是「本機測過就算過」？如果兩者都不是，你判斷「這次該多測哪個環境」的標準是什麼？

今日重點回顧

• 「本機測試通過」在多環境專案裡，只是矩陣裡一個很小範圍的驗證結果，不是全面的安全保證
• AI 預設會選擇成本最低的驗證路徑（通常是本機直接執行），這個選擇會悄悄縮小「已驗證」的實際範圍
• 不需要每次都測遍整個矩陣，但要先判斷「這次改動性質上會不會碰到某個環境維度特有的行為」
• 把「該驗證哪個環境」對照到「改動的性質」，能把難以窮盡的矩陣問題，收斂成一個可以具體判斷的問題

明日預告

明天用一個具體案例把今天的概念落地：AI 沒考慮到某個平台特有的行為，導致一次看似安全的改動，在特定環境下引入了回歸。